I think you should add some zdoom functionality to vavoom, like doing slopes the way zdoom does it, pathnodes for monsters, cameras etc, etc This could encourage map/modmakers to use Vavoom Also it would be great to implement 'Unrealistic' actor classes (they're easy to deal with, and powerful - from the viewpoint of a modmaker), portal surfaces (like Unreal 1 map DM-Eliza ( ??? or something like that)), mirrors (like zdoom, but there is a way to do it on thin walls in GL), and reflective surfaces (like ZanZan TC's first level floor in ZDoomGL)

What's the difference between the way Vavoom and ZDoom do slopes?<br><br>Pathnodes for monsters = ? (but sounds cool <!-- s:) --><img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" /><!-- s:) -->)<br><br>cameras = cool<br><br>reflective surfaces: it would use a LOT of power, wouldn't it?<br><br>Yes, I want mirrors too, I just forgot about it (last time this idea surfaced was back in mid-2000 or even earlier)<br><br>Unreal actor classes... what are they capable of? do you have a feature list?<br><br>Portal surfaces = ?<br><br>Oh my, I start to feel real ignorant...  ???

ZDoom does slopes with line special and are very limited, but it can be easy implemented.<br><br>Pathnodes - new enemy AI that uses them is "the real thing". Will implement ... somewhere later.<br><br>Cameras - already not a big problem.<br><br>Mirrors (reflective surfaces are exactly the same thing) - maybe one day...<br><br>Portals - hmmm, maybe<br><br><br>'Unrealistic' actor classes - vell, VavoomC already does have such possibility, but there are a lots of things to do and right now I am heavily working exactly on this subject. Expect a lots of changes in this area!

I believe cameras can already be done in VavoomC in current version, simply by altering SetViewPos() in user.vc... so it's just a matter of adding an ACS special for this.

i didn't mean the monster AI navigation code (altough it would be WAY COOL combined with the actual bot code)<br><br>i meant setting up routes for monsters to follow via things with arg1 to next node's tid (like the wyvern does it in hexen), or just in quake maps: monsters follow routes, until they see the player (use notarget and watch them)<br>

I think full ZDoom compatibility would be cool, because then I could use all the specials in ZETH knowing they will definantly work... (I use ZETH to make Vavoom levels...)

With pathnodes I understood something similar to Quake.<br><br>I will implement more ZDoom linedef types as whell as Boom support, most likely it won't be a full Boom support, i.e. some features will not work.

Do you plan to add the UWindow, HUD Classes of UT menu to client porgs? (with different resoulution versions of course)<br><br>And a great addon would be some sort of animation system with tweening using external lumps to support Q2 models better (like player model animation seq defs, i really looking forward to see EvilBastard's Battle Angel Alita Q2 player model in Vavoom <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->)<br><br>i mean something like this:<br><animname>: <modelname> #<frame1#> [#<frame2#> ...]<br><br>like:<br>walk: "models/players/alita/tris.md2" #0 #1 #2 #3 #4 #5<br><br>to play the anim:<br>mesh.playanim ("walk", 1.0) - plays anim at normal spd<br>mesh.tweentoanim ("pain", 0.5, 0.7) - tween to anim from current in .5 secs and play the new anim somebit slower<br><br>Some more ideas:<br>-Vwep support (ask JDoom modeler Cheb he probably would be intersted)<br>-Model "fatness" variations by moving model's vertices along their normals in/out (UT mutator 'Fatboy' RULES)<br>-more complex skyboxes<br>-plug in mutators<br><br>it would be cool just to see just one of my whishes in vavoom...

I don't know how about entire UI, but in next version menus will be fully object-oriented. Not exactly like in UT, but something very similar.<br><br>I have an idea about animation scripts, something similar to the "American McGee's Alice".<br><br>Vwep  ??? what's that?<br><br>"fatness" - if you mean scaling then it's not a problem.<br><br>Skyboxes - sure.<br><br>Plugins - support for multiple packages or progs is planed.

"Fatness" is not really scaling. It's like font weight, while scaling would be represented by font size. If you ever saw the Fatboy mutator in UT, or played on DM-Pressure with depressurizing camera, you might have seen this effect. <br><br>What about mouse input in GUI? Cursor and such...

UI with mouse is not a problem. Maybe even in next version.

Vwep support.... in quake2 this became popular and was eventually made an official addition....<br><br>You see the models in quake2 were actually 2 models for a player, the player model and the weapon.  Somebody eventually made a mod where it would cycle through different weapon models on the player model according what weapon the player was wielding.  What it would look like is if the doom marine model was holding a plasma rifle the rifle the model is holding would be the plasma rifle a rocket launcher would result in him holding that.....<br><br>The silly thing I always thought about that though is in q2 if the player was holding that blaster pistol the model still stuck to its regular animations would try to wield that pistol like a rifle<br><br>AAAAAAAnywho that's vwep<br><br>The md2 support as it is now could use a little bit of work because it basically just maps one frame of md2 animtion to each sprite animation which kinda makes the animation look very..... blocky<br><br>Raziel's a good idea for that though to make it smoother.... but how about this....<br><br>PPM support like so<br><br>Basev/game/players/skinname/<br><br>Inside that folder you'd have your model and inside each player model folder would be this....<br><br>Vavmppm.ini<br><br>The ini would then define the model(s) to use in this plugin the reason i say models is quake2 models use a player model and weapon model and this would be a relatively quick fix to allow you use q2 models in as an extra feature to this port (though both would require the same amount of frames of animation otherwise the next section will get rather complex).  Once you get that set you have a section where you map model frames of animation to doom animations like...<br><br>PLAYA-PLAYD = (some replacement frames)<br><br>BUT allow it to map multiple frames of animation to 1 doom frame.  For the sake of smoothness.  For example if you map 8 frames of walk animation to this model for the 4 doom frames it would run 2 frames of md2 animation for every 1 doom sprite frame of animation if its 12 md2 frames well you get the point. <br><br>Skins for the model would then be any pcx in the folder and the player should be able to see whichskins are working and not.<br><br>In the end though this would be cool because you take ANY md2 out there and turn it into a doom player mode

Striker:<br><br>The silly thing you mentioned could easily be solved in the UT way of creating 2 animation sets: one for 'big' weapons (like RL or plasma) and one for 'small' weapons like the pistol. (un unrealed open mesh viewer, and look at the player animations)<br><br>or better: do it halflife style where every (well, not every but most of them) weapon model<br>had it's own animation<br><br>(and Vwep stands for: 'Visible Weapons')

Well .... I must say that Vavoom already supports Vwep, i.e. you already can see your oponents weapon. Vavoom does this a little bit different. In player's model directory there's weapon.md2 with a single triangle which defines weapon position. The second frame of the weapon's ground model then is placed like defined by this triangle.

Oops ::), sorry i just figured it out today, but i didn't understood the mechanism by myself...<br><br>Better not say anything until I check...  :-/<br><br>(i think i use too much smileys <!-- s;) --><img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" /><!-- s;) -->)